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Abstract 

if 

A  wide  variety  of  line-drawing  algorithms  can  be  derived  by  applying  program  transformations  to  a 
simple,  obviously  correct  algorithm.  Ihe  transformations  increase  the  algorithm's  performance  and 
eliminate  the  need  for  floating-point  computations.  Two  familiar  algorithms  are  derived  in  this 
way:  Urcsenham's  algorithm  and  the  digital  differential  analyzer  (DDA).  The  transformations  are 
then  used  to  derive  several  highly  parallel  variants  of  Brcscnham's  algorithm,  designed  for  use  on 
displays  that  can  generate  more  than  one  pixel  at  a  time.  lTic  treatment  shows  a  complete, 
extended  example  of  the  practical  use  of  program  transformations.  Moreover,  the  transformations 
derive  Brcscnham's  algorithm  without  recourse  to  complex  geometric  arguments. 
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1.  Introduction 

Many  computer  graphics  devices  use  "line-drawing  algorithms"  to  approximate  the  appearance 
of  straight  lines  on  devices  that  can  only  produce  dots  on  a  discrete  grid.  Incremental  pen  plotters 
that  move  a  pen  in  small  steps  arc  common  devices  that  require  such  a  line-generation  algorithm. 
Point-plotting  CR  T  displays  use  the  algorithms  to  approximate  straight  lines  on  interactive  graphics 
displays.  More  recently,  frame-buffer  raster-scan  displays  use  these  algorithms  to  identify  the 
picture  elements  (pixels)  that  should  be  illuminated  to  display  a  line. 

Simplicity  and  speed  the  the  key  design  criteria  for  line-drawing  algorithms,  because  the 
computations  are  often  implemented  in  hardware  in  order  to  achieve  high  line-generation  speeds.  It 
appears  that  the  early  popularity  of  the  binary  rate  multiplier  (URM)  was  due  entirely  to  simplicity, 
for  it  generates  rather  poor  approximations  to  straight  lines  Ihc  digital  differential  analyzer  (DDA) 
generates  better  approximations  to  die  true  line,  but  requires  an  iterative  loop  that  may  average 
almost  two  cycles  to  generate  each  point.  An  algorithm  devised  by  J.H.  Hresenham  [l|  dominates 
the  DDA:  it  generates  the  optimal  line,  in  a  sense  of  optimal  described  below;  it  requires  only 
integer  additions  and  subtractions;  and  it  generates  one  output  point  for  each  iteration  of  the  inner 
loop. 

To  achieve  very  high  line-generation  speeds,  we  need  algorithms  that  can  determine  the 
location  of  several  points  on  a  line  in  parallel.  None  of  the  current  line-drawing  techniques  is 
suitable,  as  they  trace  out  the  line  sequentially,  one  point  at  a  time.  Parallel  algorithms  have  several 
applications,  chiefly  in  raster-scanned  systems  that  can  write  more  than  one  pixel  at  a  time  into  the 
image.  Ihc  "8x8  frame  buffer  display"  [2],  which  can  in  one  memory  cycle  write  a  square  region  8 
pixels  on  a  side  located  anywhere  on  the  screen,  motivated  the  investigation  of  parallel  algorithms. 

This  paper  shows  how  simple  program  transformations  are  used  to  derive  all  of  these 
algorithms,  starting  from  obviously  correct  algorithms  based  on  simple  analytic  geometry.  These 
transformations  assure  us  that  the  more  efficient  but  more  complex  algorithms  are  correct,  because 
they  have  been  derived  by  correct  transformations  from  a  correct  algorithm. 


2.  Line-drawing  preliminaries 

The  line-drawing  problem  is  to  determine  a  set  of  pixel  coordinates  (v,  \  ).  where  v  and  y  arc 
integers,  that  closely  approximates  the  line  from  die  point  (0,0)  to  the  point  (/)*.  dy).  for  integer 

values  of  dx  and  dy.  Ihc  assumption  that  one  line  endpoint  is  at  (he  origin  loses  no  generality, 

because  lines  with  other  origins  arc  simply  translations  of  the  line  with  origin  (0.(1).  Additionally, 

lines  arc  restricted  to  the  first  octant:  0  <  <ly  <  dx.  Again,  this  assumption  lose-,  no  generality, 

because  an  arbitrary  line  can  be  generated  by  transposing  the  canonical  line  or  by  reflecting  it  about 
one  of  the  principal  axes. 
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Ihc  objective  of  a  line-drawing  algorithm  is  to  enumerate  those  pixels  that  lie  closest  to  the 
true  line,  the  mathematical  line  from  (0.0)  to  (</x  dy).  Figure  1  illustrates  a  typical  line,  showing 
with  circles  the  pixels  that  correspond  to  spots  illuminated  by  a  CR  I  beam  on  a  raster  display  or  to 
the  swath  of  a  plotter  pen.  Notice  that  integral  values  of  coordinates  locate  pixel  centers. 


Figure  !.  The  line  from  (0.  0)  to  (8.  5).  Small  dots  represent  pixel 
centers.  The  solid  line  represents  the  "true"  line.  Circles  show  the 
pixels  that  are  illuminated  to  display  the  optima!  line. 

The  optimal  line  will  illuminate  exactly  one  pixel  in  each  vertical  column.  Ihis  assumption 
minimizes  variations  in  pixel  spacing  that  make  lines  appear  to  vary  in  width  or  brightness.  Ihc 
assumption  depends  on  the  fact  that  the  line's  extent  in  x  exceeds  its  extent  in  y. 

The  line-drawing  algorithm  must  compute,  for  each  integer  xf  the  coordinate  y-  of  the  pixel 
that  should  be  illuminated.  The  coordinate  y  t  of  the  true  line  is  simply  yt  =  (dy/clx)Xj. 
Illuminating  a  pixel  centered  at  r(  introduces  an  error  ev  =  Jl~y!  =  yl~(dy/dx)xr  measured  along 
the  y  axis.  The  error  c ^  measured  perpendicular  to  the  line  can  be  determined  using  similar 
triangles  (Figure  2):  =  (dx/  V  (dx*  +  dy))ev.  Thus,  for  any  given  line,  e is  simply  a  constant 

times  ev  Consequently,  determining  by  minimizing  the  error  cv  will  identify  the  pixel  that  is 
closest  to  the  line,  using  cither  vertical  or  perpendicular  distance  measures. 

The  errors  can  be  minimized  if is  computed  by  rounding  yf:  y-  =  rountAyt).  or  equivalently. 
y  =  trundyl+  1/2)  =  L;;+  1/2J.  (Recall  that  the  floor  function.  LxJ.  denotes  die  greatest  integer 
less  than  or  equal  to  x.)  With  this  choice,  ry  =  Lyf+  1/2J  -v.,  so  -  1/2  <  cy  <  1/2.  Lines  with 
this  error  behavior  arc  said  to  be  optimal,  in  the  sense  that  each  pixel  illuminated  is  within  one-half 
unit  of  the  true  line.  Optimality  thus  requires  that  a  single  pixel  be  illuminated  in  each  column  and 
dial  the  pixel  be  the  one  closest  to  the  true  line 
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dx 

Figure  2.  Illustration  of  the  relationship  between  the  vertical 
distance  and  the  perpendicular  distance  ey 


3.  Derivation  of  the  Rresenham  algorithm 

The  minimum-error  formulation  of  the  optimal  line  leads  directly  to  a  simple  algorithm  that 
enumerates  all  the  points  on  the  optimal  line,  which  can  be  expressed  in  a  Pascai  -like  language: 

AT.  var  yt:  exactreal;  dx,  dy,  xi,  yi:  integer; 
for  xi  :  =  0  to  dx  do  begin 
yt  :  =  [dy/dx|*xi; 
yi  :  =  trunc(yt  +  [l/2]); 
display(xi.yi) 
end 

Although  this  procedure  is  expressed  using  programming-language  constructs,  it  requires  that  precise 
real  arithmetic  is  used;  "floating-point"  approximations  arc  not  permitted.  To  emphasize  this 
precise  arithmetic,  variables  that  use  it  arc  declared  to  have  type  exactreal.  Square  brackets  enclose 
expressions  whose  values  do  not  change  during  iteration  of  the  loop;  these  expressions  can  be 
computed  only  once,  before  the  loop  is  entered,  and  saved  in  temporary  variables.  We  shall  also 
maintain  that  multiplications  by  a  power  of  two  do  not  require  multiplication  operations,  but  can  be 
achieved  by  addition  or  arithmetic  shifting. 

1.  Incremental  transformation.  ITic  next  version  of  the  algorithm  is  derived  from  A1  by 
observing  that  yt  can  be  calculated  incrementally  by  adding  the  quantity  (dy/dx)  on  each  iteration. 
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A2:  var  yt:  exactreal:  dx.  dy,  xi,  yi:  integer; 

yt  :=  0; 

for  xi  :  =  0  to  dx  do  begin 

yi  :=  trunc(yt  +  (l/2]);  (•  assen  yt  =  (dy/dx)xi  •) 

display(xi,yi); 

yt  :=  yt+[dy/dx] 

end 

2.  Substitution  of  variable  (simple).  A  simple  transformation  substitutes 

ys  =  >,+  1/2  (l) 

A3:  var  ys:  exactreal:  dx,  dy,  xi,  yi:  integer; 

ys  :=  1/2; 

for  xi  :=  0  to  dx  do  begin 

yi  :=  trunc(ys);  (*  assert  ys  =  (dy/dx)xi  +  l/2  =  yt  +  1/2  •) 

display(xi.yi); 

ys  :=  ys  +  [dy/dx] 

end 

3.  Substitution  of  variable  (complex).  Algorithm  A3  is  further  transformed  by  breaking  ys  into 
integer  and  fractional  parts:  ysj,  which  will  take  on  only  integer  values,  and  ysj-,  which  will  hold 
only  fractional  values.  Thus 

>s  =  ySi  +  v  (2) 

0  <  ysf  <  1  (3) 

This  substitution  requires  that  the  incremental  step  (>'s  :  =  >s+ [</>/<& I)  be  changed  to  add  the 

increment  to  the  fractional  part  (ysy)  and  then  test  whether  the  result  exceeds  1,  i.e.,  to  see  if  it  is 

no  longer  fractional. 

A4:  var  ysf:  exactreal:  dx,  dy,  xi,  ysi:  integer; 

ysi  :  =  0;  ysf  :  =  1/2; 

for  xi  :=  0  to  dx  do  begin 

(•  assen  ysi  +  ysf=yt+ 1/2  *) 
display(xi.ysi); 

if  ysf+Jdy/dx]  >  1  then  begin 
ysi  :=  ysi  + 1; 
ysf  :  =  ysf  +  [dy/dx  -  1) 
end  else  begin 

ysf  :=  ysf + (dy/dx) 


end 
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4.  Substitution  of  variable  (simple).  Algorithm  A4  can  be  easily  transformed  into  the  Bresenham 
algorithm  by  replacing  the  use  of  y^  with  that  of  a  variable  r: 

r  —  2  dy  +  2(y$j —  1  )dx  (4) 

The  objectives  of  this  transformation  are  ( 1 )  to  change  the  comparison  in  the  inner  loop  to  a  sign 
check  (i.c..  a  comparison  with  0).  and  (2)  to  eliminate  division  operations  by  scaling  by  2 dx. 
Making  the  appropriate  substitution  of  r  into  A4  yields  the  Bresenham  algorithm: 

A5:  var  dx.  dy.  xi.  ysi,  r;  integer; 

ysi  :=  0;  r  :=  2*dy  — dx; 
for  xi  :  =  0  to  dx  do  begin 

(•  assert  v\  *  1/?  --  >m  *  >st  ysi  *  (Ir  *  ?dx  -  My)/2dx  *) 

display(xi.ysi); 
if  r  >  0  then  begin 
ysi  :  =  ysi  + 1 : 
r  :=  r-|2*dx-2*dyj 
end  else  begin 
r  :=  r  +  (2*dy] 
end 
end 

The  Bresenham  algorithm  is  ideal  for  implementation  in  hardware  or  microprocessors  with  limited 
arithmetic  power.  The  algorithm  requires  neither  division  nor  multiplication,  and  requires  no 
"floating-point"  approximations  because  all  variables  take  on  only  integer  values.  Moreover,  r  is 
not  required  to  hold  large  values.  Liquations  (3)  and  (4)  imply 

2dy-2dx  <  r<  2 dy  (5) 

If  0  <  dy  <  dx  <  2"— 1,  r  is  bounded  by 

-2"  +  1+2  <  r<  2,+1-I  (6) 

Thus  if  dx  and  dy  are  //-bit  positive  integers,  r  requires  at  most  n+2  bits  in  a  two’s  complement 
representation. 

Interpretation  of  r.  Ihc  value  of  r  is  minted  to  the  vertical  error.  er  the  distance  from  the  pixel 
center  to  the  true  line.  Ihc  errors  will  be  identical  for  all  algorithms,  because  the  same  sequence  of 
points  is  generated.  When  display  is  called,  ey  =  J’j Using  (1)  to  substitute  for  yf.  and  then 
(2)  to  substitute  for  jj,  we  have 

ev  =  T’i'j-  0'5  1/2)  =  y si~  (y si+ sf~  ^2) 

ey  =  1/2  ~ysf 

Applying  transformation  (4)  yields 
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ev  =  ~(r+  dx—2dy)/(2dx)  or 

r/(2dx)  =  -ev+(dy/dx- 1/2) 

The  value  r  is  thus  linearly  related  to  but  is  offset  by  1/2  due  to  the  loop's  initial  conditions, 
and  is  moreover  scaled  by  2dx  to  require  only  integral  values  of  r. 

Summary.  Ah  of  the  algorithms  developed  in  this  section  compute  the  same  sequence  of  points 
( Xj ,  y.)  that  approximate  the  true  line.  Mathematical  and  program  transformations  are  used  to 
derive  efficient  implementations. 


4.  The  digital  differential  analyzer  (I)DA) 

The  digital  differential  analy/cr  numerically  integrates  the  line  equation,  obtaining  x  =  {dx 
and  y  =  {dy.  The  conventional  DDA  treats  both  coordinates  symmetrically.  The  numerical 
integration  requires  choosing  the  number  of  integration  steps,  as  shown  in  the  following  algorithm: 

A6:  var  x.y:  exactreal;  dx,  dy,  nsteps:  integer; 

x  :=  0;  y  :=  0; 

nsteps  :  =  some  number  >  dx  and  >  dy, 
for  i  :=  0  to  nsteps  do  begin 

display!  trunc(  x  +  [  1  /2]).trunc(y  +  [  1  /2])); 
x  :=  x  +  [dx/nstcps]; 
y  :  =  y  +  [dy /nsteps) 
end 

This  algorithm  generates  exact  values  for  x  and  y  in  the  loop  because  "exact"  real  arithmetic  is 
used.  This  algorithm  may  not  produce  the  optimal  line,  in  the  sense  defined  in  Section  2,  because 
of  the  separate  rounding  in  x  and  y.  A  trivial  example  arises  if  nsteps  =  I :  only  the  pixels  at  the 
two  endpoints  of  the  line  will  be  displayed.  A  more  interesting  example  arises  when  dx  =  10,  dy 
-  8,  and  nsteps  is  chosen  to  be  40:  the  point  (2,  1)  is  displayed,  even  though  its  vertical  error  is 
-0.6. 

An  important  problem  with  the  DDA  is  the  choice  of  nsteps.  A  common  approach  is  to  choose 
nsteps  to  be  a  power  of  two  so  that  the  divisions  may  be  performed  simply  by  shifting  dx  and  dy: 
thus,  nsteps  =  2",  where  2"  >  dx.  Unfortunately,  this  causes  x  to  be  incremented  by  a  quantity 
less  than  unity,  so  that  more  than  one  pixel  in  a  column  may  be  illuminated.  Although  the  second 
pixel  in  a  column  can  be  omitted  by  a  suitable  test  in  the  loop,  it  is  harder  to  guarantee  that  the 
pixel  that  is  displayed  is  the  one  closest  to  the  line. 

Another  approach  is  the  "unit  increment"  DDA,  in  which  we  choose  nsteps  =  dx  so  that  x  will 
always  be  incremented  by  unity,  and  algorithm  A6  becomes  identical  to  A2.  which  generates  the 
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optimal  line.  By  this  route,  the  DDA  transforms  into  the  Bresenham  algorithm. 

It  is  important  to  note  that  a  common  approximation  to  the  unit  increment  DDA,  often  used  in 
hardware  implementations,  docs  not  generate  optimal  lines.  The  approximation  is  obtained  from  A4 
by  substituting  y^j  for  0-n)ysj-  in  order  to  introduce  an  integer  variable  iJ(.y  that  has  "sufficient" 
precision  to  represent  the  fractional  part  of  the  y  coordinate. 

A7:  var  dx.  dy,  xi.  ysi,  ysd:  integer; 

ysi  :=  0;  ysd  2n~l; 

for  xi  :=  0  to  dx  do  begin 
display(xi.ysi); 

if  ysd+[2n*(dy/dx)-e)  >  2n  then  begin 
ysi  ysi  +  l; 

ysd  :=  ysd  +  [2n*(dy/dx)-£-2n] 
end  else  begin 

ysd  :=  ysd  +  (2"*(dy/dx)-e] 

end 

end 

The  above  algorithm  is  precise  only  if  e=0.  In  practice.  2 ”(dy/dx)-i  is  chosen  to  be  integral,  and 
e  is  the  error:  -1/2  <  e  <  1/2.  The  value  of  n  is  chosen  to  be  sufficiently  large  that  errors 
introduced  by  the  approximation  arc  acceptably  small.  If  n  is  chosen  to  be  the  smallest  integer  such 
that  2"  >  dx.  the  line  is  guaranteed  to  begin  and  end  at  the  proper  coordinates,  but  not  to  be 
optimal.  To  illustrate  the  non-optimality,  consider  dx  =  120,  dy  =  1,  n  =  7.  At  xi  =  62.  the 
algorithm  will  call  display{62,  0).  However,  the  point  (62,  1)  is  closer  to  the  true  line.  Ihere  is  a 
value  of  n,  2"  »  dx.  for  which  the  generated  line  will  be  optimal.  However,  this  value  may  be  quite 
high. 

The  hardware  implementation  of  the  unit-increment  DDA  is  simpler  than  algorithm  A7 
implies  (Figure  3).  On  each  iteration,  which  corresponds  to  a  clock  cycle  in  the  circuit,  a  new  value 
for  y is  computed  by  adding  2 n(dy/dx)~  t,  ysj  will  be  incremented  if  the  sum  equals  or  exceeds 
2",  and  will  always  increment.  The  same  idea  can  be  used  to  build  a  fixed-point  software 
implementation. 
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Figure  3.  Hardware  implementation  of  the  unit-increment  DDA. 
Counters  compute  x(  and  y. .  An  adder  sums  y..j  and  a  — 
2 n(dy/dx)-t.  On  each  cycle,  yS(j  is  loaded  with  the  new  sum,  xi  is 
incremented,  and  y  -  is  incremented  if  the  high-order  bit  of  the 
adder  result  is  1. 


5.  An  n-step  algorithm 

Before  exploring  algorithms  that  exploit  parallelism,  we  shall  illustrate  the  transformation 

techniques  developed  in  the  previous  sections  by  deriving  an  algorithm  that  takes  horizontal  steps  of 
n  units  in  x.  Such  an  algorithm  will  generate  every  oth  point  on  the  line.  We  start  with  an  obvious 
variant  of  Al: 

NT.  var  yt:  exactreal;  dx,  dy,  xi,  yi,  n:  integer; 

for  xi  ;=  0  do  dx  by  n  do  begin 

yt  ;  =  [dy/dx|*xi; 

yi  :=  trunc(yt+ 1/2); 

display(xi.yi) 
end 

Computing  yt  incrementally,  and  substituting  y$  =  y(+\/2,  we  have; 

N3:  var  ys:  exactreal:  dx,  dy,  xi,  yi,  n:  integer; 

ys  ;=  1/2; 

for  xi  :  =  0  to  dx  by  a  do  begin 

yi  :=  trunc(ys); 

display(xi.yi); 
ys  :=  ys  +  [n*(dy/dx)) 
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When  ys  is  broken  into  integer  part  ysi  and  fractional  part  ysj-  nUly/dx)  may  also  have  an  integer 
and  fractional  part.  Define  the  integer  part  .v  so  that  0  <  n(dy/dx)-s  <  1;  the  "fractional"  part  is 
then  n(dy/dx)-s.  which  although  called  fractional,  may  actually  equal  1.  A  value  of  s  that  meets 
these  constraints  is  s  =  Ln(dy/dx)J.  Ihe  algorithm  becomes: 

N4:  var  ysf:  exactreal:  dx.  dy.  xi,  ysi.  n.  s:  integer; 

(•  assume  s  has  been  computed  *) 
ysi  :  =  0;  ysf  :  =  1/2; 
for  xi  :  =  0  to  dx  by  n  do  begin 
display(xi,ysi); 

if  ysf-f  |n*(dv/dx)-s]  >  1  then  begin 
ysi  :=  ysi  +  [s+l]; 
ysf  :  =  ysf+(n*(dy/dx)-s—  1] 
end  else  begin 
ysi  :=  ysi  +  s; 
ysf  :=  ysf+|n*(dy/dx)-s] 
end 
end 

The  next  step  is  to  apply  the  transformation  that  makes  a  "Brescnham-likc”  algorithm:  r  =  Indy  + 
2  (ysj~  1  -  s)dx. 


N5:  var  ysf:  exactreal:  dx,  dy,  xi,  ysi,  n,  s,  t:  integer; 

(•  assume  s  and  t  =  2nd>  -  2sdx  have  been  computed  *) 
r  :=  t— dx;  (*  ysf  =  \n  implies  r  =  2ndy  +  2(1/2- 1  -s)dx  *) 

ysi  :=  0; 

for  xi  :=  0  to  dx  by  n  do  begin  "N51oop" 

display(xi.ysi); 
if  r  >  0  then  begin 
ysi  :=  ysi  +  [s+l]; 
r  :=  r-[2*dx-tj 

end  else  begin 
ysi  :=  ysi+s; 
r  : =  r+t 

end 

end  "N51oop" 

Note  that  this  algorithm  is  identical  to  A5  if  «=1.  s=0.  ihe  attentive  reader  will  question  what 
happens  if  dy-dx.  «=i.  Note  that  s  is  not  defined  to  be  Ln(dy/dx)A.  So  by  setting  s  =  0  in  this 
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case,  the  assumption  0  <  it(dy/dx)—s  <  1  is  not  violated.  1  he  other  possibility  for  dy=dx ,  j=  I, 
generates  the  same  points,  although  the  algorithm  is  then  not  identical  to  A5. 

A  minor  difficulty  with  N5  is  the  need  to  compute  v  and  t  -  huh  -  lsd\.  Although  this  could 
be  done  with  multiply  and  divide  operations,  a  small  incremental  algorithm  can  be  used  to  compute 
s,  developed  using  the  same  principles  shown  in  A1-A5: 

var  nn;  e \  (/cl  real:  s.  i,  n:  integer: 
s  :  =  0.  mi  :  =  0; 

for  i  :  -  0  to  n  - 1  do  begin 
if  mi  +  |dy/dx|  >  1  then  begin 

s  :  =  s+  1; 

mi  :  =  mi  +|dy/dx  - 1| 
end  else  rm  :=  im  +  (dy/dxj 

end 

Ihis  program  is  transformed  by  substituting  t>  -  {nn  1),/<  +  </i  and  including  obvious  calculations 
for  I  into  the  following  prologue  to  algorithm  N5: 

N5p:  var  dx.  dy.  s.  t.  rp.  i,  n:  integer; 
begin  "\5pro)ogue" 
s  :  =  0;  t  :=  0: 
rp  :=  dy  — dx; 

for  i  :  =  0  to  it  1  do  begin 

;  (*  assert  ildv/dvt  s-irp*d’  dvi-'dx  *) 

L  t  :  =  t  +  dy: 

if  rp  >  t)  then  begin 

|  s  :  =  s  +  1 ; 

.  i  l  :  -  t'-dx: 

rp  :  -  rp  [dx  -  dy] 
end  else  rp  :  -  rp-i-dy 

end; 

t  ;=  t  +  t; 
end  ”N5prologue" 

!  It  is  important  to  remember  that  the  n  step  algorithm  generates  the  same  optimal  points  as  the 

i  Brcscnham  algorithm. 
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6.  Parallel  algorithms 

This  section  develops  line-drawing  algorithms  that  are  capable  of  generating  several  points  on  a 
line  in  parallel.  Iticse  algorithms  arc  useful  if  a  frame  buffer  can  update  several  pixels  in  one  cycle, 
or  if  lines  must  be  approximated  with  special  "characters"  |T  4],  The  transformations  illustrated  in 
the  preceding  sections  arc  extremely  useful  in  designing  these  algorithms.  They  allow  the  algorithm 
to  be  stated  in  conceptually  simple  terms  and  then  transformed  into  one  that  can  be  efficiently 
implemented  with  integer  arithmetic. 


6.1.  The  (n.n)  algorithm 

The  n-step  algorithm  developed  in  Section  5  is  the  basis  for  a  parallel  algorithm:  operate  n 
copies  of  the  procedure,  each  generating  points  spaced  n  units  apart:  hence  the  name  (n.n).  Hach 
copy  of  the  algorithm  is  phaseil  slightly  differently:  the  copy  with  phase- 0  generates  points  at  jk  =  0, 
n.  In.  .  .  .:  the  copy  with  phase=  I  generates  points  at  x=  1.  ;i+l,  2n+l.  .  .  .;  and  so  on.  Ibis 
technique  is  simply  expressed  as  (c.f.  A I  >: 

PI:  var  phase:  integer: 

for  phase  :  =  0  to  n  - 1  do  parbegin 

var  xi.yi:  integer:  yt:  exact  real:  (*  Iticse  variables  are  duplicated  for  each  phase  *) 
for  xi  :=  0+ phase  to  dx  by  n  do  begin 
yt  :  =  [dy/dx]*xi; 
yi  :=  trunc(yt  +  (J/2J); 
display(xi.yi) 
end 
pa  rend 

The  bracketing  parbegin  and  parend  mean  that  there  arc  n  parallel  copies  of  the  inner  loop,  each 
operating  with  a  different  value  of  phase  and  with  separate  copies  of  the  local  variables  xi,  yi,  and 
yt.  We  now  proceed  with  transformations  demonstrated  in  Sections  3-6.  'Ihc  inner  loop  is 
transformed  into  one  almost  identical  to  the  inner  loop  of  N5;  only  the  iteration  of  xi  is  different. 
The  initial  computation  for  jr  in  P2  requires  a  multiply/divide  which  is  transformed  into  a  loop 
executed  phase  times  to  compute  initial  values  for  ysi  and  r.  This  loop  is  combined  with  the 
prologue  (N5p)  to  compute  values  for  s  and  I.  The  final  result  is  P2: 
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P2:  var  dx.  dy.  s.  t,  n.  rp.  i.  phase:  integer; 

begin  "N5prologue"  (*  Prologue  is  identical  to  N5p  above  *) 
s  :=  0;  t  :=  0: 
rp  :=  dy— dx; 

for  i  :  =  0  to  n  - 1  do  begin 

(•  assert  Kdy/dx)  =  s-t  (rp  t-  dx  -  dy)/dx  •) 

t  :=  t+dy; 

if  rp  >  0  then  begin 

s  :=  s+1; 

t  ;=  t-dx; 
rp  ;=  rp-|dx-dy] 
end  else  rp  :=  rp  +  dy 

end; 

t  :=  t+t; 
end  "NSpnlogue" 

for  phase  :=  0  to  n-1  do  parbegin 

var  xi,  ysi.  r.  i:  integer;  (•  Thc<  variables  arc  duplicated  for  each  phase  *) 
r  :=  t-dx: 
ysi  ;  =  0; 
begin  "P2init" 

for  i  :=  0  to  phase  — 1  do 
if  r  >  |t-2*dy)  then  begin 
ysi  :  =  ysi  + 1 ; 
r  :=  r-[2*dx-2*dy] 
end  else  r  -  r+|2*dy] 
end  ”P2init" 

for  xi  :=  0+ phase  to  dx  by  n  do  begin  "i  21oop" 

(•  Kxactly  (he  same  code  as  NSIoop.  above.  *) 
display(xi.ysi); 
if  r  >  0  then  begin 
ysi  :=  ysi  +  [s+1]; 
r  :=  r — [2*dx  —  t] 
end  else  begin 
ysi  :=  ysi+s; 
r  :=  r+t 
end 

end  "I’lloop" 
pa  rend 

Notice  that  the  loop  P2init  corresponding  to  the  initial  computations  for  ys  bears  a  strong 
resemblance  to  the  1-stcp  Brcscnham  algorithm.  A5;  the  difference  arises  because  of  the  slightly 
different  expressions  for  r.  Thcic  is  no  particular  virtue  to  executing  the  It  Kips  in  parallel— one  loop 
can  be  used  to  compute  initial  values  of  ysi  and  r  for  all  phases. 
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6.1  The  (l.n)  algorithm 

The  second  algorithm  capable  of  exploiting  parallelism  uses  the  //  step  algorithm  to  find  points 
on  the  line  at  //-unit  intervals  and  fills  points  in  between  with  a  "stroke."  The  n  pixels  in  each 
stroke  can  be  written  in  parallel.  This  technique  is  useful  when  lines  musi  he  approximated  with 
"characters"  because  a  raster  displa>  or  printer  is  controlled  bv  a  character  generator;  the  characters 
arc  simply  short  strokes. 

Ihc  algorithm  is  easily  derived  from  N5.  In  the  inner  loop,  the  test  on  r  determines  whether 
the  line  rises  by  s+1  or  s  units  for  a  more  of  «  units  in  x  If  the  line  rises  by  s  +  1  units,  a  stroke 
that  rises  s+1  units  in  n  is  drawn  from  the  current  (x  y)  point.  Ihc  stroke  is  determined  by  an 
index  /  that  gives  its  rise  in  y.  r=0.  1.  .  .  .  n.  The  strokes  mar  he  precomputed  using  the 
Bresenham  algorithm,  as  shown  in  Figure  4  for  /t-8.  Note  that  each  stroke  has  only  n  points 
(x  =  0,  1.  ...  n-  1).  but  that  the  rise  is  that  of  the  (n+  l)st  point  (x  =  n).  This  convention  is  adopted 
because  algorithm  N5  computes  the  rise  to  the  origin  of  the  next  stroke  rather  than  the  rise  to  the 
end  of  the  current  stroke. 
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Figure  4.  Ihc  nine  different  strokes  for  //  =  8.  The  left  column 
shows  rises  of  0  (bottom).  1,  2,  3,  and  4  (top).  The  right  column 
shows  rises  of  5  (bottom),  6,  7,  and  8  (top).  I  he  origin  of  a  stroke 
is  marked  with  a  +  and  the  origin  of  the  next  stroke  with  an  x. 
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In  order  to  draw  lines  of  arbitrary  length,  the  last  stroke  on  the  line  may  be  only  a  partial 
stroke.  The  standard  stroke  is  simply  truncated:  only  the  first  few  points  on  it  are  actually 
displayed.  Ihis  is  illustrated  by  the  procedure  DisplaySiroke.  which  accesses  an  array  Stroke[i,x\  to 
find  the  y  coordinate  of  a  pixel  given  the  stroke  rise  t  and  the  x  coordinate  relative  to  the  beginning 
of  the  stroke. 

procedure  DisplayStrokc(originX,  originY,  rise.  maxX:  integer); 
var  x:  integer: 

for  x  :=  0  to  maxX  do  parbegin 

display(originX  +  x.  originY  +  Strokcjrise.x]) 

pa rend; 

Note  that  the  individual  pixels  of  the  stroke  arc  written  in  parallel. 

This  procedure  can  be  incorporated  into  N5  to  yield  the  complete  line-drawing  algorithm  Q. 
The  algorithm  is  shown  without  the  prologue  N5p: 

Q:  var  dx,  dy,  xi,  ysi.  s,  t.  r:  integer; 

(•  Insert  N5p  here  to  compute  s  and  t  =  2ndy-2sdx  *) 
r  ;=  t-dx; 
ysi  :  =  0; 

for  xi  :=  0  to  dx  by  n  do  begin 
if  r  >  0  then  begin 

I)isplayStrokc(xi.  ysi.  s+1.  min(n-  l,dx-xi)) 
ysi  :=  ysi  +  (s+l]; 
r  :=  r-[2*dx  — t] 
end  else  begin 

DisplayStrokc(xi.  ysi.  s.  min(n  -  l.dx  —  xi)) 
ysi  :=  ysi  +  s; 
r  :=  r+t 

end 

end 

Algorithm  Q  has  several  advantages  over  P.  Ihe  setup  is  substantially  simpler,  as  are  the 
computations  performed  in  parallel.  The  scheme  is  very  similar  to  that  of  a  character  generator  in 
which  pre-computcd  patterns  arc  displayed:  the  strokes  play  the  role  of  characters.  It  differs  from 
many  character  generators  in  that  a  character  may  have  an  arbitrary  origin  on  the  screen  and  may 
be  partially  truncated. 

Ihe  chief  disadvantage  of  algorithm  Q  is  that  it  docs  not  generate  optimal  lines.  Although  the 
stroke  origins  lie  within  1/2  unit  of  the  true  line,  the  other  points  along  the  stroke  may  err  by  as 
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much  as  1  unit.  Ibis  property  arises  because  the  i  coordinate  of  a  pixel  is  the  sum  of  two 
independent  computations,  the  position  of  the  stroke  origin  and  the  position  of  the  pixel  withir  the 
stroke,  each  of  w  hich  may  make  an  error  of  i/2.  .An  example  of  a  vertical  error  of  0.913  is  shown 
in  the  top  line  of  Figure  6.  at  x  -  18.  Another  way  to  see  the  non-optiinality  of  Q  is  to  observe 
that  although  only  a  single  stroke  is  displayed  for  each  distinct  rise  in  there  are  actually  several 
different  strokes  with  the  same  rise  (Figure  5).  In  practice,  the  error  is  hardly  noticeable. 
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Figure  5.  Four  of  the  8  different  strokes  with  n-  8  and  a  rise  of  1. 

Before  leaving  the  subject  of  stroke  selection,  we  should  mention  that  it  is  essential  to  have  the 
algorithm  P2  choose  from  two  strokes,  rather  than  merely  position  the  origin  of  a  single  stroke.  If  a 
single  stroke  is  used  for  an  entire  line,  the  maximum  deviation  from  die  optimal  line  may  be  greater 
than  1  or  the  line  may  have  gaps  or  non-monotonicities,  illustrated  in  Figure  6. 

F.vcn  though  algorithm  0  produces  non-optimal  lines,  it  turns  out  that  die  endpoint  of  the  line 
is  always  exact.  Appendix  A  contains  a  proof  of  this  fact.  Fxhaustivc  simulations  of  algorithm  Q 
for  all  lines  of  length  1024  or  less  have  verified  that  endpoints  are  always  computed  correctly. 

7.  Conclusion 

This  paper  began  by  showing  how  simple  mathematical  and  program  transformations  could  be 
used  to  transform  an  obvious  line-drawing  method  based  on  analytic  geometry  into  an  efficient  and 
exact  algorithm  that  requires  only  integer  arithmetic.  Ihcse  methods  help  persuade  us  that  the 
algorithm  is  correct  without  recourse  to  complex  geometric  constructions  such  as  those  in  [1],  Ihc 
techniques  are  examples  of  routine  program  transformations  that  should  he  a  commonplace  activity 
in  program  design  and  implementation. 
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Figure  6.  l  ines  illustrating  gaps  and  non-monotonicitics.  The  top 
line  (dx  =  23.  dy= 18)  is  drawn  with  three  strokes  with  «  =  8,  which 
leave  a  gap.  The  small  dots  show  the  optimal  line.  Ihe  bottom 
line  (dx-  23,  dy=  5)  shows  a  non-monotonicity. 


The  main  reason  for  applying  these  techniques  is  to  extend  line-drawing  algorithms  to  exploit 
parallel  activities.  Although  only  two  parallel  schemes  are  explored  in  Section  6.  one  can  imagine 
many  more.  The  difficulty  of  developing  such  algorithms  is  subtantially  reduced  by  using  the 
program  transformations. 
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Appendix  A 

We  demonstrate  that  the  ( 1 ./;)  algorithm  terminates  at  the  proper  endpoint  idx.dy)  Assume  dx 
>  dy  >  0.  let  Z  =  ax  +  by  be  the  measure  of  disunit  e  from  the  line,  and  further  let  a  -  2d),  b  = 
-  2dx.  Define  ,r(  to  be  the  y  coordinate  o.  the  pixel  displayed  at  x  =  i:  z,  is  the  distance  from  this 
pixel  to  the  true  line. 

The  Bresenham  algorithm  that  generates  the  origin  for  a  stroke  will  guarantee  that  |zj  < 
-b/2.  Ihc  points  x  =  ni  +  j  for  /  =  1  to  n  are  members  of  one  of  the  two  strokes  that  represent 
a  line  of  slope  s/n.  where  s  is  the  vertical  distance  from  the  origin  of  the  stroke  to  the  origin  of  the 
next  stroke  (i.e..  s  =  yni.  „  -  ym).  If  these  pixels  arc  generated  by  a  Bresenham  algorithm  aiming 
at  a  line  of  slope  s/n.  then  we  will  have  \zni+J  -  (J/nHznj+n  -  •?„,)!  <  -b/2.  for  0  <  j  <  n—  1. 
We  consider  two  cases:  first,  that  the  expression  is  positive,  and  second,  that  it  is  negative. 

1.  We  have  zn  <  (//«Xzm+n  -  zn)-b/2.  From  the  triangle  inequality,  we  also  have 

|z  _  t  |  <  -b  However,  the  equality  ease  never  occurs — if  it  did.  the  slope  of  the  line 
• n/+n  nr  — 

would  be  an  integer  multiple  of  \/n  and  the  zm  would  be  zero  for  all  /.  So  we  now  have:  |zm>||  - 
Zm I  <  -b.  For  1  <  j  <  n/2.  this  yields  zm+j  <  -  b. 

2.  The  negative  ease,  by  similar  argument,  gives  zn/+,  >  b  for  1  <  j  <  n/2. 

Both  cases  together  give  |zm4  /|  <  -b  for  1  <  ./  <  n/2.  By  a  similar  argument  approaching 
from  the  other  side  (i.e..  x  —  ni  +  n.  ni  +  n  —  1,  .  .  .).  we  obtain  <  —  b  for  1  <  j  <  n/2. 

Both  forward  and  backward  approaches  together  give  \z„i+j\  <  -b  for  1  <  <  n. 

W'hen  jr  =  dx.  at  the  endpoint  of  line,  we  must  have  <  -  b.  which,  together  with  the  fact 
that  z  must  be  a  multiple  of  b  forces  zJx  =  0.  Ihereforc.  the  last  point  lies  exactly  on  the  line. 


